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Abstract;  This  paper  reviews  some  of  the  control  structures  that 
have  become  popular  in  new  extensions  to  LISP-based  programming 
languages*  A  method  for  constructing  these  complex  control 
structures  that  employs  LISP  features  without  the  cost  of  double 
evaluation  is  developed*  This  technique ,  called  the  direct  LISP 
approach ,  uses  the  LISP  functions  FUNCTION  and  EVAL  to  maintain  and 
manipulate  function  access,,  environments*  _ .  Control  environment 
manipulation  Is  accomplished  using  continuation  pointers  ana  lambda 
expressions*  This  approaoh  factors  funotion  execution  into  two 
distinct  steps*  First  the  funeton  is  associated  with  an  environment 
and  then  ^ it  is  . invoked*  The  normal  LISP  evaluation  routines 
retrieve  the  associated  environments  and  apply  the  function*.  This 
method  allows  the  programmer  flexibility  to  design  oomplex  oontrol 
structures  without  expensive  overhead  oosts*  Several  examples  that 
employ  the  direct  LISP  approaoh  are  presented  and  discussed* 


Artificial  Intelligence  (AI)  research  reveal  a  trend  toward  features  that 
support  suspendable  processes ,  coroutines  ,  retention  of  environments  between 
function  activations ,  generator  functions ,  and  styles  of  computing  not  present 
in  other  high  level  languages.  These  new  control  constructs  provide  superior 
metaphors  for  the  complex  modes  of  processing  required  in  many  AI  cognitive 
models  and  permit  a  user  both  to  alter  the  normal  control  flow  of  a  program's 
execution  and  to  aocess  variable  bindings  in  differing  environments.  The 
Implementations  of  these  new  features  are  based  on  manipulating  the  control 
and  access  environments  associated  with  a  function,  facilities  previously 
inaccessible  to  the  user  of  a  language*  While  these  new  constructs  provide  an 
extended  set  of  operations  for  the  user ,  they  are  often  costly  to  implement 
and  expensive  to  execute. 

This  paper  examines  several  LISP  programming  techniques  that  aid  a  user 
to  construct  complex  control  structures  with  little  overhead.  Manipulation  of 
a  function's  control  and  access  environment  is  achieved  using  built-in  LISP 
functions ,  requiring  neither  modification  to  the  basic  evaluator  mechanisms 
nor  implementation  of  a  second-level  language.  The  direct  LISP  approach 
provides  an  efficient  and  powerful  alternative  to  previous  methods  for 
constructing  new  control  paradigms. 

Extensions  to  LISP'S  basic  control  repertoire  of  recursion,  selection 
(l.e.  conditionals)  ,  and  Iteration  require  modification  of  the  strategies  for 

retaining  control  and  aooess  environments.  New  constructs,  such  as 
suspendable  processes,  may  retain  control  information  past  the  point  that  it 
is  normally  accessible  during  function  evaluation.  This  new  retention  polioy, 
combined  with  the  need  for  user  accessibility  to  this  information,  requires 
that  the  normal  staok-based  implementation  of  the  LISP  evaluator  be  modified. 
One  approaoh  is  to  oontruot  a  new  mechanism  to  be  used  by  the  evaluator  to 
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maintain  environments ,  and  ia  exemplified  by  Infcerliap'a  "spaghetti  stack"*  A 
second  aethod  is  to  represent  the  control  and  aooeaa  environaents  as  LISP  data 
structures  and  to  implement  an  evaluator  for  a  new  language  containing  the  new 
constructs.  This  approach  has  been  adopted  by  several  languages  (e»g. 

CONNIVER  ,  Micro-PLANNER ,  SCHEME  [Suasman75]) •  The  former  approach  requires 
substantial  modification  of  the  LISP  evaluator ,  while  the  latter  suffers  from 
slow  execution  caused  by  a  double  evaluation »  first  at  the  language  level  and 
then  at  the  LISP-EVAL  level* 

The  dlreot  LISP  approach  is  an  efficient  implementation  of  control 
constructs  that  employs  LISP  functions  without  the  use  of  a  second  level 
interpreter*  Modification  of  aoceas  environments  is  accomplished  using 

FUNCTION;  a  feature  that  associates  the  binding  environment  with  a  user 

function ,  and  EVAL;  an  explioit  oall  to  the  LISP  evaluation  mechanism* 
Manipulation  of  the  control  environment  is  achieved  by  continuation  passing;  a 
technique  of  including  a  function's  return  point  as  an  argument  to  the 

function's  invocation,  and  LISP'S  equivalent  treatment  of  program  and  data* 
permitting  a  function  to  be  dynamically  constructed  and  then  executed. 

This  paper  examines  and  compares  the  two  approaches  to  control  structure 
extension  exemplified  by  CONNIVER  and  Interlisp*  The  techniques  for  access 
and  control  environment  manipulation  in  LISP  are  presented  and  accompanied  by 
several  examples.  The  dlsousslon  concludes  by  assessing  the  relative  power 

t 

and  efficiency  of  this  new  approach  to  oonstruot  new  control  structures. 

2*  Background 

Interest  in  language  features  that  would  support  "hairy  control" 
atruotures  originated  with  CONNIVER  [McDermott? 4] *  a  language  conceived  as  a 
response  to  faults  found  in  Micro-Planner  [Susaman71].  which  Itself  was  a 
partial  implementation  of  Hewitt's  PLANNER  language.  While  not  the  first 
language  to  oontaln  features  such  as  processes  and  generators*  CONNIVER  was 
one  of  the  first  languages  based  on  the  philosophy  that  the  user  should  have 
aoceas  to  and  be  able  to  modify  the  state  of  the  computation.  This  design 
philosophy  was  in  part  a  reaotion  to  PLANNER'S  hidden  goal  tree  *  which 
contained  essentially  the  same  information  as  CONNIVER 's  control  tree*  but  was 
unavailable  to  the  user* 

CONNIVER  paokages  a  function's  control  environment  (CLINK) *  aooeaa 
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environment  (ALINK) ,  Internal  variables  used  during  evaluation,  Including 
registers  and  the  PC  (IVARS) ,  and  local  variables  introduced  by  the  function 
(BVARS)  into  a  user  accessible  data  structure  called  a  frama.  This  permits 
functions  to  suspend  their  execution  and  then  be  restarted ,  exeoute  and  return 
to  another  frame's  caller,  or  use  the  aooess  environment  of  another  function 
to  look  up  the  bindings  of  non-local  variables*  While  CONNIVER  contains  other 
new  features  (e.g*,  a  context-layered  data  base)  ,  its  greatest  influence  on 
other  languages  has  been  the  use  of  user-aooesslble  frames* 

CONNIVER  was  Implemented  in  LISP  and  suffers  from  a  slow  evaluation 
process ,  first  at  the  CONNIVER  language  level  and  then  at  the  LISP  Interpreter 
level*  It  was  used  sparingly  in  actual  research  (Fahlman's  BUILD  program 
[Fahlman73l  was  the  major  exception  to  this)*  Other  languages  extracted  the 
frame  philosophy  and  integrated  this  feature  directly  into  the  language  design 
(e»g* ,  Trlgg[79]  discusses  a  frame-based  LISP  interpreter) • 

Another  approach  to  implementing  language  constructs  that  manipulate  the 
evaluation  environments,  is  to  reorganize  the  mechanisms  of  the  evaluator,  in 
particular,  the  format  of  the  stack*  During  normal  function  invocation  and 
execution,  values  and  control  information  are  pushed  and  popped  from  the 
system  stack*  If  user  manipulation  of  environments  is  permitted,  then 
sections  of  the  staok  that  normally  would  be  re-used  must  be  preserved*  This 
causes  the  staok  to  become  tree-like  in  appearance  (and  in  fact  CONNIVER  has  a 
control  tree  constructed  of  CONS  nodes)*  To  implement  the  tree-like  behavior 
in  a  true  stack,  link  information  describing  the  format  of  the  tree  must  be 
Included  in  the  staok*  This  was  the  approaoh  taken  by  [Bobrow73]  in  creating 
the  "spaghetti  stack"  of  Interlisp* 

Both  of  the  approaches  of  CONNIVER  and  Interlisp's  spaghetti  staok  are 
based  on  the  same  philosophy;  that  when  the  user  oalls  a  function  he  specifies 
the  envlronmenfc(s)  to  use  during  the  execution*  The  direct  LISP  approaoh 
separates  the  invocation  of  a  funotion  into  two  distlnot  operations,  namely 
the  association  of  an  environment  with  a  funotion  and  later  the  application  of 
the  funotion  in  the  associated  environment*  While  this  approaoh  is 
restrictive  in  comparison  with  CONNIVER ,  many  complex  CONNIVER-llke  control 
structures  can  nevertheless  be  constructed.  In  the  following  sections  several 
examples  demonstrating  the  power  of  tbs  dir sot  LISP  approach  are  presented* 


3. 


Tha  Funotlon  FUNCTION 


The  LISP  funotlon  FUNCTION  explicitly  assoolatas  an  access  environment 
with  an  evaluated  lambda  expression^  When  the  FUNCTION* ed  lambda  expression 
Is  applied ,  the  aooess  environment  present  when  FUNCTION  was  exeouted  Is  used 
to  locate  free  variable  bindings  during  the  execution  of  the  lambda 
expression*  The  use  of  the  binding  (or  definition)  environment  during 
funotlon  execution  contrasts  with  LISP's  normal  use  of  the  activation  (or 
runtime)  environment*  When  the  LISP  Interpreter  encounters  a  FUNCTION' ad 
lambda  expression ,  the  our rant  aooess  environment  Is  temporarily  saved  and  the 
binding  access  environment  installed  before  the  lambda  expression  is  executed* 
Upon  oompletlon  of  the  funotlon  exeoutlon ,  the  previously  stored  aotivation 
environment  is  reestablished  and  the  result  of  the  exeoutlon  returned  to  the 
oaller* 

User  specification  of  whioh  environment ,  binding  or  aotivation ,  is  to  be 
acoessed  during  function  exeoutlon  is  a  powerful  feature  not  present  in  many 
higher  level  languages*  In  LISP,  the  FUNCTION  feature  solves  what  has  been 
named  the  FUN  ARC  problem,  In  whioh  the  use  of  functional  arguments  that 
contain  references  to  free  variables  can  oause  unanticipated  results  (see 
[Moses70]  for  a  complete  dlaoussion)*  To  demonstrate  the  power  of  the 
FUNCTION  mechanism  In  a  role  other  than  solving  the  FUN ARC  problem,  an 
Implements ton  of  the  LISP  funotlon  CONS  is  presented*  This  version  of  CONS 
delays  the  evaluation  of  Its  arguments  until  the  function  CAR  or  CDR  is 
applied  to  the  fora  return  by  CONS*  The  environment  present  during  the 
exeoutlon  of  CONS  must  be  retained  until  the  oall  to  CAR  (or  CDR)*  This  type 
of  delayed  evaluation  is  due  to  CFriedmanAWise76]  and  their  investigation  of 
the  semantics  of  CONS  and  Hewitt's  ACTOR  semantics  (Hewltt77]«  Figure  1 
oontalns  an  encodings  of  the  function  CONS  and  a  sequence  of  function  calls 


.  *The  lambda  expression  Is  then  referred  to  as  a  FUNCTION 'ed  or  closed 
lambda  expression  as  contrasted  with  lambda  expressions  that  execute  In  their 
aotivation  environment* 

2The  examples  In  thls^paper  are  coded  in  Maryland  LISP  [Agre78]*  Lambda 
expressions  ari  represented  using  the  following  notation: 


(LAMDA  <arg  llst>  <bodles> 
,  t<arg  llst>  <bodles> 
(<arg  llat>  <bodlos>  fa 


Unevaluated  lambda  expression 
Evaluated  lambda  expression 
Lambda  expression  dosed  in 
environment 


where:  <arg  llst>  Is  the  argument  list  of  the  LAMBDA  expression. 


that  demonstrates  the  power  of  delayed  evaluation  using  FUNCTION.  The  keyword 
FEXPR  types  the  CONS  function  as  being  a  speoial  fora  that  does  not  evaluate 
its  arguments  when  it  is  called*  CAR  and  CDR  are  regular  foras  that  do 
evaluate  their  arguments* 


(defun  fO  () 

(f3  (fl  2  3))) 


(defun  oons 
(funotion 


fexpr  (argl 
(lambda  (sel 
(oond 


-if*’  , 

Kswtfri 


(aval  argl)) 
(aval  arg2)) 


“a%n !*  b> 

(defun  f2  (b) 
(cons  a  b)) 


(defun  oar  (fora)  (fora  'oar)) 
(defun  odr  (fora)  (fora  'odr) 


(defun  f3  (a) 


-  _  fun  f3 

[print  (oar  a))) 

(defun  f4  (b) 
(print  (odr  b))) 


Figure  1:  Definition  of  CONS  and  the  Calling  Sequence 


The  Initial  call  is  to  the  function  F0»  The  exeoution  of  the  calling 
sequence  proceeds  in  a  straightforward  Banner  until  the  call  to  CONS  in 
funotion  F2*  FUNCTION  establishes  a  pointer  to  the  current  association  list, 
preventing  it  from  being  garbage  collected ,  and  returns  a  closed  laabda 
expression  containing  that  pointer  to  CONS's  caller  F2  (and  eventually  to  FO 
where  TEMP ,  an  explicit  representation  of  the  internal  register  that 
aocuaulates  the  result  of  the  oall  to  FI ,  is  bound  to  the  dosed  laabda 
expression)*  The  funotion  F3  is  then  Invoked  and  passed  the  result  of  the 
oall  to  FI  (l*e*  ,  TEMP).  F3  calls  Ft  whloh  contains  a  oall  to  the  funotion 
CDR  (during  the  evaluation  of  the  argument  to  PRINT)*  Figure  2  shows  the 
state  of  the  computation  during  the  oall  to  CDR* 

When  CDR  is  Invoked  it  places  its  parameter  FORM  on  the  current 
association  liat  (denoted  Ee  in  Figure  2)*  When  the  S-expreasion  (FORM  'CDR) 
la  evaluated  in  the  body  of  the  CDR  funotion,  the  old  association  list,  Eq, 
becomes  the  current  aooesa  environment  (the  one  pointed  to  by  E«  is  stored  in 
an  internal  register) •  The  funotion  bound  to  FORM  is  applied  and  its  argument 
SEL  is  CONSed  on  the  front  of  the  current  association  list  (and  pointed  at  by 

<bodles>  is  the  list  of  S-expressions  in  the  body  of  the  LAMBDA 
expression* 

The  access  environments  are  represented  using  an  association  list  of  bindings 
shown  as  CONS  nodes  with  the  CAR  field  pointing  to  the  name  of  the  variable 
and  the  CDR  field  pointing  to  the  variable's  value* 
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Figure  2:  State  of  Computation  during  call  to  CDR 


&••)«  Execution  of  the  FUNCTION'ed  lambda  expression  looks  up  ARG2  which  is 
bound  to  B  ,  evaluates  B  (executes  the  S-expression  (EVAL  ARG2)  In  the  body  of 
the  lambda  expression)  ,  and  returns  the  value  4 ,  which  was  the  original  second 
argument  to  CONS*  When  the  olosed  lambda  expression  completes  execution,  the 
association  list  corresponding  to  Es  is  recovered  and  the  binding  for  SEL  is 
garbage  collected*  The  association  list  segment  pointed  at  by  Eq  is  still 
retained  since  the  binding  for  A  (and  B)  in  E«  (i*e.  the  FUNCTION'ed  lambda 
expression)  oontains  a  pointer  to  E0,  During  the  evaluation  of  (PRINT  (CAR 
A))  a  similar  process  occurs* 

The  CONS  example  demonstrates  the  power  of  FUNCTION  not  only  to  associate 
an  execution  access  environment  with  a  function ,  but  also  to  retain  an  access 
environment  past  the  point  that  it  would  normally  be  garbage  collected* 
Techniques,  similar  to  those  employed  in  the  CONS  example  and  based  on  the  use 
of  FUNCTION  to  manipulate  environments ,  have  been  used  to  construct  complex 
control  paradigms*  Small [80 ]  has  implemented  a  natural  language  parser 
organized  as  a  series  of  interacting  coroutines ,  called  "word  experts" ,  that 
are  suspended  and  reamed  during  the  processing  of  a  sentence.  Each  word 
expert  routine  is  implemented  as  a  olosed  lambda  expression,  that  when 
activated  restores  the  context  of  the  word  in  the  sentenoe  before  reaming 
execution* 

4.  Manipulating  the  Control  Environment ;  Continuation  PolUtara 

The  CONS  example  demonstrates  the  flexibility  available  to  a  LISP 
programmer  for  designating  whioh  environment  to  use  when  aooessing  variables* 
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In  a  similar  vain ,  there  are  instances  when  the  normal  stack-like  function 
call  and  return  sequenoe  of  the  LISP  Interpreter  la  insufficient  and  needs  to 
be  modified*  Coroutines  and  generators  require  that  the  state  of  the 
computation  be  retained  between  funotion  calls*  This  includes  not  only  the 
binding  of  variables  and  the  access  environment *  but  also  the  control  path  and 
the  continuation  point  for  the  calculation*  FUNCTION  provides  a  method  for 
manipulating  access  environments;  control  structure  modifications  can  be 
accomplished  using  continuation  pointers. 

A  continuation  pointer  is  an  expliolt  reference  to  the  funotion  that  will 
be  invoked  when  the  currently  executing  function  has  completed*  Normally  the 
continuation  point  of  a  function  is  implicitly  the  next  expression  of  the 
caller  ,  and  provides  the  standard  call-return  sequence  that  is  implemented 
using  a  stack*  In  continuation  passing  *  control  is  passed  from  one  function 
to  another  without  any  function  ever  necessarily  returning  control  back  to  its 
caller*  The  value  of  the  executing  function*  which  would  normally  be  returned 
to  the  caller*  is  passed  as  an  argument  to  the  continuation  point* 
Continuation  passing  factors  the  calculation  of  the  return  address  and  its 
placement  on  the  stack  into  two  dlstinot  activities*  unlike  normal  function 
invocation.  In  continuation  passing*  the  calling  function  explicitly 
specifies  the  return  point  for  the  called  function  *  while  the  called  function 
determines  when  to  pass  oontrol  to  the  continuation  point*  The  continuation 
point  (in  the  form  of  a  lambda  expression)  is  similar  to  CONNIVER's  CLINK  of  a 
function's  frame. 

Continuation  passing  provides  an  efficient  implementation  of  a  solution 
to  the  Samefrlnge  problem,  a  commonly  cited  example  of  interrupted  evaluation* 
The  task  is  to  design  a  funotion  that  will  determine  whether  the  fringe  (set 
of  terminal  nodes)  of  two  trees  is  the  same  *  regardless  of  the  internal 
structure  of  the  tree*  One  solution  to  this  problem  is  to  calculate  the 
oomplete  fringe  of  both  trees  and  then  do  an  EQUAL  test  on  the  generated 
fringes*  This  method  is  oostly  in  the  case  that  the  two  trees  differ  in  the 
first  few  nodes  of  the  fringe*  An  alternate  method  oaloulates  the  first 
member  of  each  fringe  *  compares  them ,  and  continues  calculating  the  successive 
members  of  the  fringes  only  while  they  are  the  same.  This  method  has  the 
property  that  it  will  halt  at  the  earliest  point  the  fringes  differ* 

To  realize  this  behavior*  a  standard  recursive  tree  traversal  routine  is 
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modified  to  suspend  (i»e» ,  momentarily  halt  and  return  a  value)  when  it 
generates  a  member  of  a  fringe  and  resume  at  the  same  point  when  reinvoked* 
Figure  3  is  an  encoding  of  a  set  of  functions  for  the  Samefrlnge  problem,  in 
which  the  function  FRINGE  has  the  property  that  it  can  be  interrupted*  The 
FRINGE  function  takes  two  arguments,  the  tree  (or  subtree)  to  be  traversed , 
TREE ,  and  the  function  to  be  invoked  when  FRINGE  has  finished  the  traversal , 
CP*  FRINGE  is  called  via  RESUME  which  accepts  a  dotted  pair  whose  CDR  field 
points  to  a  closed  lambda  expression*  RESUME ,  after  verifying  that  it  has  a 
function  call ,  applies  this  expression  to  call  FRINGE.  STARTUP  builds  the 
first  pair  for  RESUME  to  get  the  whole  thing  rolling3(  The  lambda  expression 
that  RESUME  applies  has  been  FUNCTlON'ed  causing  the  binding  environment  of 
the  lambda  expression  to  be  reestablished  before  execution. 


(defun  samefrlnge  (treel  tree2) 

(prog  ((trl  (startup  fringe  treel)) 
,(tr2  (startup  fringe  tree2))) 


loop 


setq  trl 
lset<j  tr2 


(resume  trl). 
(resume  tr2)) 


oond  ((or  (eq  (get-val  trl)  'done) 

„  (.IStTOTysLW 

((eg  (get-val  trl)  (get-val 
(t  (return  nil))))) 


pal  _tr2)jj) 


trff^  Igo  loop 


(defun  fringe  (tree  cp) 
(cond  ((atom  tree)  (c 


(t  (fringe 


.cons  tree  cp)) 
car  tree) 


.flacLLoa  (lambda  ()  **,.*,* 

(fringe  (edr  tree)  cp) )))))) 

(defun  get-val  (pair)  (and  (not  (atom  pair))  (car  pair))) 

(defun  resume 
(not  ( 

((edr  pair) 


lerun  resume  (pair) 

(and  (got  (atom  oalr)) 


(is- function-call  (edr  pair)) 


Figure  3:  Samefrlnge  code 


A  sample  execution  of  the  Samefrlnge  functions  demonstrates  the  power  of 
this  technique*  The  trees  in  this  example  are  the  S-expressions  ((A  *  B)  .  C) 
and  (A  ,  (B  •  C))*  The  representation  for  the  trees  affects  only  the  traversal 
routine  and  this  technique  can  be  extended  to  other  representations  and 
routines*  Initially ,  SAMEFR1NGE  calls  FRINGE  (from  RESUME)  with  argument 
TREE1*  Prior  to  each  recursive  call  to  FRINGE  a  FUNCTlON'ed  lambda  expression 
Is  formed  that  will  invoke  FRINGE  on  the  CDR  of  the  ourrent  value  of  TREE 


where  <tree>  is  either  TREEi  or  TREE2  depending  on  the  exaot  call* 
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after  FRINGE  has  completed  the  CAR  of  TREE.  FRINGE  recur sea  until  the  first 
aeaber  of  the  fringe,  A,  is  loeated  (i.e.  ,  the  ATOM  check  succeeds).  The 
FUNCTION 'ed  lambda  expression,  bound  to  CP,  is  CONS'ed  with  the  newly  found 
member  of  the  fringe  and  returned  to  SAMEFRINGE,  The  association  list  segment 
constructed  during  the  calls  to  FRINGE  is  not  garbage  oollected  because  it  is 
referenced  by  the  closed  lambda  expression  ,  which ,  in  turn ,  is  bound  to  TR1 
(or  TR2). 

In  a  similar  manner ,  FRINGE  is  Invoked  with  TREE2  and  locates  the  first 
member  of  its  fringe,  A.  This  situation  is  depicted  in  Figure  4,  Note  that 
the  association  list  segment  from  the  first  call  to  FRINGE  (with  TREED  has 
been  retained  and  a  new  association  list  segment  corresponding  to  the  second 
call  to  FRINGE  with  TREE2  (denoted  by  E#t )  has  been  added  to  the  structure  and 
points  to  the  common  section  that  contains  the  bindings  of  TREE1  ,  TREE2 ,  TR1 , 
and  TR2.  Once  again  part  of  the  current  association  list  will  be  retained 
when  FRINGE  returns  because  it  is  pointed  at  by  the  FUNCTION' ed  lambda 
expression  that  is  bound  to  TR2  when  FRINGE  returns. 


The  calculation  continues  with  each  member  of  the  fringe  of  each  tree 
being  generated  and  oheoked  against  the  other  before  calculating  subsequent 
fringe  members.  When  the  final  member  of  TREEI's  fringe,  C,  is  returned  and 
bound  to  TR1 ,  the  last  remaining  pointer  to  E^  is  removed  and  that  association 
list  segment  is  finally  garbage  collected.  Figure  5  shows  the  computation 
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during  the  calculation  of  TREE2'a  final  fringe  member*  Upon  coapletlon  of  that 
calculation  the  association  list  segments  pointed  to  by  Eei  ,  Ei* ,  E3 ,  and  Ee 
will  be  reclaimed* 


Figure  5:  Calculation  of  the  final  fringe  member  of  TREE2 

Figure  6  points  out  an  unnecessary  inefficiency  in  this  scheme  for 
manipulating  the  retained  environments*  During  the  calculation  of  the  final 
member  of  TREE2's  fringe,  it  is  not  necessary  to  retain  the  E3  and  E4 
association  list  segments*  They  are  retained ,  in  fact ,  because  the  next 
association  list  segment  points  at  them  (E4  points  at  E3  and  Ee*  points  at 

£4)*  The  association  list  is  constructed  in  a  stack-like  manner  because  of 
the  dynamic  scoping  rules  for  non-local  variable  lookup*  FRINGE  references 
only  the  variables  in  its  parametbr  list  and  does  not  invoke  any  functions 
that  require  non-local  lookup*  Thus  when  FRINGE  is  executing,  it  needs  only 
the  association  list  segment  that  its  frame  adds  to  the  system's  association 
list*  The  same  mechanism  that  modifies  the  normal  LISP  access  environment, 
FUNCTION,  can  solve  this  seeming  inefficiency  of  the  Samefringe  problem,  if 
FRINGE  (snd  SAMEFRINGE,  GET-VAL,  and  RESUME,  for  the  same  reason)  is  closed  in 
its  binding  environment  (i.e*,its  definition  is  FUNCTION'ed) .  This  will 
cause  the  association  list  structure  to  have  a  higher  branching  factor  than  in 
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the  example ,  but  each  association  list  segment  will  be  retained  only  as  long 
as  it  Is  needed*  In  the  example*  the  £4  segment  would  have  been  retained* 
without  the  need  to  retain  £3, 

5.  Cloaurea 

Beyond  the  methods  for  designating  which  environment  (binding  or 
activation)  will  be  accessed  during  function  execution ,  there  are  situations 
that  require  a  combination  of  both  static  and  dynamic  scoping.  In  such 
situations  the  programmer  might  need  to  specify  which  variables  will  access 
the  state  of  the  computation  at  definition  time ,  and  which  variables  will  be 
sensitive  to  the  current  state  of  the  computation. 

One  mechanism  for  meeting  this  need  is  the  CLOSURE  function  (a  term 
introduced  by  the  LISP  machine  [Greenblatt77]).  CLOSURE  takes  a  function  and 
a  list  of  variables  to  be  closed  (variables  in  the  binding  environment)  *  and 
returns  a  function  that  when  invoked  will  use  the  binding  environment  for 
looking  up  closed  variables  and  the  activation  environment  for  all  other  free 
variables. 


The  Implementation  of  the  CLOSURE  function  proposed  by  Greenblatt[77] 
uses  a  special  type  of  cell  called  an  invisible  pointer  that  the  evaluator 
treats  differently  from  a  normal  cell.  This  feature  can  be  simulated  by 
allowing  EVAL  to  take  a  second  argument ,  an  association  list  to  be  used  for 
variable  look  up  during  the  EVALuatlon  *  and  maintaining  an  explicit  record  of 
the  closed  variables.  Figure  6  contains  an  enooding  for  the  function  CLOSURE. 


(defun  closure  (v-lst 
(eval  (list  'lambda 
(list  'eval 


(a: 

(1 

(1 


args) 

list  (list  'eval  fh)  '(stack  args)) 
list  'append 

(list  'quote 

((lambda  (a-lst) 

,  (into  v-lst  (lambda  (x) (assoc  x  a-lst)))) 


CLOSURE  returns: 

I(arga)(eval  ((eval  <fn>)(stack  args) ) (append  ' (<a1.v(a1 )>•••) (alist)))] 
<ai.y(al)>  is  a  pointer  to  the.  CONS. node. in  the  associatic 


binding  of  variable  ai  at  the  point  of  call  to  CLOSURE 


on  list  for  the 


Figure  6:  Closure  Funotion 


The  CLOSURE  funotion  takes 
closed  *  and  constructs 
<*i»value-of(ai)>  for  each 


the  argument  <v-lst>  *  the 
an  association  list 
variable,  ai*  in  <v-lst>. 


list  of  variables  to  be 
segment  of  the  form 
This  segment  oaptures 
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the  current  binding  of  the  a**8  during  the  execution  of  CLOSURE*  The  current 
association  list  (returned  as  the  value  of  the  call  to  the  function  ALIST)  is 
appended  to  the  end  of  the  binding  environment  segaent  and  used  as  a  second 
argument  to  EVAL  during  the  call  to  the  dosed  function*  The  expression 
((EVAL  <fn>)  (STACK  <args>))  invokes  the  function  <fn>  and  pushes  <args>  on 
the  stack  before  jumping  to  APPLY*  The  values  for  the  closed  variables  will 
be  those  from  the  binding  envlronnent  *  not  the  activation  environment  *  even  if 
there  is  another  variable  with  the  sane  name*  (Recall  that  the  association 
list  is  searched  for  the  first  occur enoe  of  the  variable  name*)  CLOSURE 
retains  the  actual  binding  (i*e* ,  a  pointer  to  the  CONS  cell  on  the 
association  list  at  the  time  of  closure)  in  the  association  list  segment  that 
is  constructed  when  it  is  executed  ,  rather  than  a  copy  of  the  binding*  This 
permits  functions  that  are  still  active  after  the  CLOSURE  call  and  able  to 
access  the  closed  variables ,  to  change  the  binding  of  the  variable  and  have 
all  the  closed  lambda  expressions  see  the  modification.  The  LISP  machine 
CLOSURE  works  in  a  similar  manner* 

6*  Coacluaioa 

■A 

The  direct  LISP  approach  for  manipulating  access  and  control  environments 
la  an  attractive  alternative  to  other  approaches  for  implementing  new  advanced 
control  structures*  The  overhead  for  employing  the  LISP  features  FUNCTION  and 
EVAL  consists  of  storing  the  retained  environment  (which  must  be  saved  no 
matter  what  approaoh  is  used)  and  executing  an  environment  switch  when  the 
function  is  activated*  In  LISP  systems  that  use  a  deep  binding  strategy*  such 
as  Maryland  LISP*  environment  swltohing  involves  exchanging  the  saved  access 
environment  pointer  with  the  system' s  association  list  pointer  *  a  oost  of 
several  assembly  language  instructions*  Continuation  passing  is  also 
inexpensive  to  employ  and  has  been  used  in  compilers  to  produce  efficient  code 
(Steele78]a  The  LISP  features  used  in  the  direct  LISP  approaoh  can  be  found 
in  most  LISP  implementations  and  require  no  modifications  to  the  host 
evaluator*  Thus  the  direct  LISP  approach  provides  an  efficient  technique  for 
extending  the  available  oontrol  structures  of  LISP* 
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